CD ROM Paradise Collection 4/CD ROM Paradise Collection 4 1995 Nov.iso/music/gus357_x.zip/README

Text File | 1994-12-13 | 18KB | 361 lines

Documentation on use is after this history text.

New history: See README.NEW.

Old history:
----------------------
4-Dec-94   Jaleo 0.67a

Added some basic mixer functions.  Works, provided you have one of those SB
cards.  Archive filename changed to jalexxxy where xxx is the version (067)
and y is the sub-version (a).  The double-o (zero-oh, actually) was causing
more trouble than I thought possible, anyway, so now there's just the zero.

Picked up Warp and Jaleo runs fine in full-screen DOS.  Just set the usual
stuff (hardware_timer, and so on).  Also works fine in a DOS window, though
you may want to set the VIEW to None, and then keep the VIEW menu dropped
down; the less screen updating the better.  If you have super-fast video,
it may not matter.  I've not had any problems with it and Warp.  I do boost
the vertical sensitivity of the mouse if OS/2 is running.  Use xx to skip.

Added a check for PATDIR= being set.  If not, it won't go.  Well, it will,
but you have to use xx (C>jaleo xx).  This skips all the startup checks
(DOS 3+, mouse, PATDIR=, 286+).  The MPU-401 & AWE32 devices don't
currently need PATDIR=, but will in the future.  If you don't want to
set PATDIR=, use the "xx" arg.  Or, just create a .bat:

        C>copy con j.bat
        set patdir=thedrivepath
        jaleo^Z
        C>j

Tune/List loop fixed.

---------------------
17-Nov-94  Jaleo 0.66

Previous versions would cause the Double Space DoubleGuard routine to report
a "bad moon rising" (and force a reboot) when used on machines that do not
implement VDS 1.0 (all 286 machines had the problem, though perhaps not the
symptom).  386+ machines using EMM386, 386MAX, QEMM, etc. did not have the
problem, since all these memory managers implement VDS.  Fixed.

---------------------
9-Nov-94   Jaleo 0.65

Previous versions were incompatible with some video BIOSes.  Fixed.

- Slap bass OPL 2op patch cleaned up a bit (was bad at low freqs)
- GUS FM LFO okay with any clock source (had required OnCard clock source)
- \ now appended to [dir=] entries of R2*.INI files, if needed
- Size keeps getting bigger because much of the R2 vox component is in this,
  and previous versions, but is not yet functional so has been "turned off"

----------------------
21-Oct-94  Jaleo 0.63z

Version included with Ruckus 1.1 shareware release. (now with the 0.65 version)

---------------------
8-Oct-94   Jaleo 0.63

MIDI files with SysEx events could cause problems in the 0.62 version
code when using the GUS device, though you may not have noticed any problem.

---------------------
26-Sep-94  Jaleo 0.62

HIMEM.SYS can now be used.

HIMEM.SYS is limited to 128 handles, and defaults to only 32.  To get 128
use /NUMHANDLES=128.  More might be available under Windows enhanced.  Best,
get 386MAX, or QEMM, or Memory/Net Commander, or something that permits more
than 128 XMS handles.  (One handle is used for each SuperCached patch, plus
one for the INI and another for housekeeping.)

----------------------
25-Sep-94  Jaleo 0.61b

This is Jaleo.  It's not quite ready for prime-time, but sure is close.
It supports MIDI playback on OPL2, OPL3 (stereo), MPU-401 (generic, and
specific support for TBS Maui and Rio), and the GUS (including SuperCache
and patch caching).

===========================================================================
How To Use Jaleo

        0. You must SET PATDIR=path of R2*.INI and OPL *.PAT files

This must be set if you play a file from other than the current directory.
For example, if Jaleo's support files are in D:\TEST, do:

        C>set PATDIR=d:\test

If you have more than one R2*.INI file, then read the following, else skip
to JUMP START.

Jaleo looks for the *.INI file in the current directory first, then in
PATDIR=.  If you have used the file manager to select a file from another
drive/directory, then when Jaleo plays that file, Jaleo looks in the
directory that Jaleo is currently in for the *.INI file.  You can check
the current directory by bringing up the FILE MANAGER dialog box.  The
current directory is shown across the bottom of the dialog window.  If
the selected device's R2*.INI file is there, then that INI is used rather
than the one pointed to by the PATDIR= environment variable.  This can
be perplexing if you don't understand what's happening because you can
edit what you believe to be the INI file and yet never have the changes
take because R2 is actually using an INI located in the then-current
directory.

GUS users see R2GUS.INI files for additional path requirements.

----------
JUMP START
----------

        1. move MC (mouse cursor) to upper-right area and click
        2. at first box (Setup), click the down arrow (or box)
        3. select MIDI
        4. change anything in the dialog box (default should be okay)
        5. select okay
        6. move MC to upper-left area and click
        7. at first box (MIDI), click on device to use
        8. change anything in the dialog box
           (default should be okay, but if OPL3 and SB-Pro, set
            base port to 2x0 (as in 220, 240, etc.))
        9. select init or cancel
           (only way to close the dialog box is to successfully init
            or to cancel)
       10. move MC to upper-right, click on FILE box down arrow
       11. select PLAY FROM
       12. at file dialog box, select drive (if needed), and move to
           any directory (if needed), then pick up to 8 MIDs
       13. select okay
       14. press Play
       15. alt-X is the only way to exit


Odds and evens and in-betweens:

1) GUS in Windows needs to use PIO (selected with DMAdiv) unless you
don't have the Gravis Windows driver installed, then you can use DMA.
The Gravis VxD prevents notification of a DMA TC IRQ and so will time-
out, or so I think.

GUS users will probably want to boost the PercEQ to +6dB or so.  This
is in the MIDI setup dialog box.  Makes a big difference.  This also
boosts the level for the OPLx and MPU-401 cards.  AWE32, perhaps, too.

2) Jaleo under Windows enhanced mode reports a CPU MHz rate always
lower than it really is (I've seen from 5% to 50% of true speed).  The
CPU Load% bar and readings, likewise, are skewed to nonsense (the
bar is pegged at 100%, as are the readings).  No ill effects -- it's
just the way Windows 3.x works.  OS/2 should report correct results for
both MHz and Load%, though it won't allow any of the font changes
(I don't think it will, anyway).

3) Not sure how any of this runs in OS/2 2.0 (not recommended when
using the DMA routines since 2.0 doesn't support VDS).  Should run
a-okay in 2.1.  OS/2 behaves more like DOS in a VDM than Windows
3.x ever could, especially when you need to get directly to the metal.
Warp?  It should do fine in Warp.

4) A short error-is text message is shown next to error numbers. See the
errcode.txt file for more detail on those.

5) Color VGA is recommended.  Mono VGA should do okay.  CGA should have
its colors mapped okay, and same with MDA, but results will be less than
intended (and not much was intended to begin with).

6) Rio/Maui users, when selecting specific support during init (i.e.,
not generic MPU-401 device), the DevLvl should be set to -6dB or lower
(as in -9, etc.).  Or, you can validate that no "DAC saturation" is
occuring by looking at the pL: and pR: (peak L/R) and sC: (saturation
count, to 32) which is updated every 7 seconds.  This info is in the
LOAD-STAT view screen, at the lower-right.  Values of 7FFF means that
that channel's DAC (left/right) is clipping.  The sC: value indicates
how many times it has clipped since the last reading (taken once every
seven seconds or so).  The access to on-board state info does tend
to slow things down, so best results when using the Rio/Maui selection
is to use a view other than LOAD-STAT, or to simply select "generic".
Using the IRQ line would improve things when waiting for specific data
from the device -- but you don't really need to read access the device
while playing something, except if you want to look at those peak levels.

6a) SB16 + Rio users may want to use a /OPGAIN:3 since lower (1 or 2)
results in too low of an output level, and 4 or higher seems to cause
the SB16 grief (especially the right channel which pops obnoxiously).
It's a shame that the Rio has to be mated to the SB16, considering how
poor quality the SB16 is (SB line in general if you want my opinion).

7) Rio/Maui users can set the number of voices if Rio/Maui support is
specifically specified (i.e., not generic MPU-401 device).  All MPU
devices play only extended WDS (Windows dual-sequenced files) correctly,
so do not select basic WDS (none is fine).  The IRQ line is not required.

8) The 4op OPL patches are included though a 4op switch in this version
is not provided.  Basically a UI problem (have to code a channel selection
routine (those 012345...EF drop menus).  They need work, anyway, but then
so do the 2op ones.  A patch editor is already available.

8a) OPL users may want to reset the device (just drop the DEVICE MIDI and
select OPLx again) to clear any remaining sound from an early out (stop
pressed).  I just noticed this (at a high volume).  The included MIDI
file sounds very good on the Rio; pretty good on the GUS, but pretty odd
on the OPLs.  If you want to move into decent sound, pick up a Turtle Beach
Maui.  About $130 mail-order.  It's a stand-alone MIDI soundcard (MPU-401
UART compatible, which is perfect).  You can use it with your current
SB, PAS, or whatever, to replace the often-funky sounding OPLx hardware.
...Night and Day.


9) The AIR value (in MIDI SETUP) should be at least 50% of DIR for good
results.  Less is okay, but you may notice slurring of notes.  Bump the
AIR (actual interrupt rate) to around 512 and all will be peachy (or try
32 if you want, or even 8192).  The GUS has an onboard clock source that
can be used (other cards currently need to use timer-0 or the RTC) and
its clock works with DIR=AIR (or close).  The GUS can also use the other
two clock sources.


10) The SuperCache system is for the GUS and can load the entire standard
patch set (5.5MB) into extended memory for near-instant loads.  Patch
caching is standard.  If full 16-bit resolution won't fit in available
GRAM (GUS RAM), a retry at 8-bit resolution is made (and R½ shown in the
LOAD-STAT view).  You can SuperCache all patches, a selected subset (see
the R2GUS.INI file for all-stars), or just the INI file.  Each patch
file SuperCached requires an XMS handle, so you may need to extend this
amount.  200 should do it.  ERR_XMSFAIL (in red, status line area) means
that you've run out of XMS handles or XMS memory.  It's not a fatal error,
and Jaleo will simply go to disk for any patches that did make it into
the SuperCache.  ERR_NOPATCHINI means the patch# Jaleo wanted to SuperCache
was not in the R2GUS.INI file.  This is expected since Jaleo attempts to
SuperCache all patches from #0 to #254.  Since the first drum in R2GUS.INI
doesn't start until D27 or so (128+27=155), you'll see 27 ERR_NOPATCHINIs
flash on the status area, and then more after the last drum in R2GUS.INI,
which is D94, so (128+94=222) you'll see 32 more ERR_NOPATCHINIs at the
end, even if you have enough XMS memory and handles.  If you don't have
enough handles available, use the "All Star" option.  See R2GUS.INI for
more.  In OS/2, unless you have lots of physical memory, you may not get
much benefit from SuperCache, since the XMS memory may simply be virtual
(disk) memory anyway, and Jaleo only calls for it once per play, or about
every few minutes (so OS/2 will more than likely swap that out, back to disk).
In case it didn't already mention, only the selected _default_ bank is
SuperCached (see MANAGER, SETUP, MIDI).


11) The mixer should be easy to figure out.  If things move to fast, hold
the alt key down.  The mixer is init'ed as soon as you select it from the
menu (unlike the other devices which let you CANCEL if you choose the
wrong one).  The port selection is taken directly from the BLASTER= setting,
and defaults to 220 if not present.  The M parm is used, if included.
You cannot change the port selection currently (as of 067a), but you shouldn't
need to.  All R2 values are 0-100, though none of the SB mixers have that much
resolution.  Therefore, you can move 10 or 20 along and not notice a change.
The right button snaps to center, or snaps the volume to the opposite end.

Alt-x exits.

---------------
Additional Info
---------------


FOR THE GUS

- The R2GUS.INI file has PISTOL.PAT used as program #127.  If you don't have
this patch file, but instead the old RINGWHSL.PAT, edit R2GUS.INI and
uncomment the RINGWHSL.PAT entry and comment-out the PISTOL.PAT.  PISTOL.PAT
is available in the GUS0043.ZIP update, or the newer GUS distribution set.

- Patch size is limited to 256K, with sample size limited to 256K.  Larger
patches can be used (512/512), but this forces all patches to be loaded in
as 8-bit (currently).

- In the R2GUS.INI file, to select alternate banks, use the MANAGER, MIDI,
SETUP dialog box (current you can select from 8 different bank setups in
the INI file).  This can also be done directly from the SMF, provided it
follows the MIDI 1.0 spec and sends both the low and high MSB (play with it).
More to come.

- See 10) above.

- See R2GUS.INI for how to use/setup bank switching.


FOR ALL

- Be sure to set the PATDIR= variable, as described above.

- If you get bored looking at the title screen, select the VIEW menu.

- And what exactly is the LOAD % you ask.  This is a measure of the amount
of time spent in the background versus nothing at all running.  This
takes into account all background tasks (e.g., the mouse registers about
a 2% peak use).

On the graphic, the green bar displays the peak usage, and the the
bright-green bar the highest peak over the last second (i.e., it holds
the highest peak encountered for each second).  This peak reading is
actually an average of usage over two periods of 1/40th of a second
(0.025sec).

So, the peak reading is the current usage over the last 1/20th of a
second, where 0% is no use, and 100% is total use.  Note that in order
for 100% utilization to occur, two 1/40th-sec periods must be completely
utilized; not a likely occurance.  You can try pressing the PAUSE key on
the keyboard momentarily, and when released, you will see a utilization
of 50%.  This because you can only pause the test code when it's doing
ONE of the two tests for the peak average, and so 100% on one test, and
0% on the other (typically), results in an average of 50%, as displayed.

The average reading, on the left, is the overall background CPU system
utilization over the last second.  In other words, it is an average (not
a running average) of 40 of the tests (each test last 1/40th of a second).

Base readings are taken at program startup, with all interrupts off (for
1/40th of a second, several runs, then averaged).

A note on LOAD %.  Since the time needed to wait for a device to respond
is indepent of CPU speed, it is possible that you may see a higher peak
% usage on faster CPUs than slow.  This because the CPU is waiting for the
device (a constant).  Typical average results for most CPUs is around 1%;
more on MPU-401 devices, to about 3%.  The MPU-401 devices may have very
high peak use, to around 30%, eventhough the average is 3% or less.  This
you will see happen, typically, at the start of play, where large amounts
of controller and/or sysex info is sent to the device.  The GUS, being
100% software programmed, won't have these momentary lapses of efficiency.

Something like that, anyway...

Jaleo was built using the current Ruckus 2 beta, available to
registered users on the BBS.


Current versions of this program, and Ruckus, the toolkit used to build
Jaleo, are available for anonymous FTP at:

[e-mail]    anon ftp to ftp.crl.com /users/ro/cornel for Ruckus & Bullet
--------------    WWW at ftp://ftp.crl.com/users/ro/cornel     ---------------
BBS/fax: [phone] / Monday-Friday after 5pm / Weekends 24 hours [-0600]

You can use this to report any problems OR any successes you are having.
If it's not working on your system, and you have read this README file,
then chances are it will continue to not work on your machine until you
report it.  Don't think "the other guy will do it", because he won't.

Case in point:  AWE32 support.  First time through (0.66) I had 4 reports.
It wasn't working.  Next time (0.67a & b) I had 1 report.  Wasn't working.
Three weeks, 5 reports (4 people) on the AWE32 support not working.  Either
there just aren't many AWE32 people seeing this program, or they really
don't care one way or the other.  So, like I said, don't think the other
guy will do it, because he won't.  This is 0.67c.  Should work.  I'm not
going to even bother with announcing it since the only thing different
from 0.67b is that the AWE32 support is working.  Maybe.  Now at 0.67d.

If you do have a problem and want to see the problem corrected, send a
report via internet e-mail, the BBS, or USMail (Cornel Huth/6402 Ingram Rd/
San Antonio Texas 78238-3915/USA) with as much detail about the problem
and your hardware that you care to provide.  The more detail, the faster
I can do my job.